great job guys.
just wondering if there is any way to get a compiled version of this.
I'm currently travelling in remote deserts in the middle of Australia and have a perfect opportunity to test this feature. there are no other humans hundreds of miles around so not much can go wrong apart from losing my wing.
i'm running Matek F405-Wing FC.

http://seyrsnys.myzen.co.uk/inav_dev/

thanks for that.

just to confirm, if using existing Configurator 2.1.4 then I need to manually adjust my servo mix like so
currently settings (2.1) -

servo mix

smix 0 3 0 50 0
smix 1 3 1 50 0
smix 2 4 0 -50 0
smix 3 4 1 50 0

new settings (2.2) becomes

servo mix

smix 0 3 0 50 0 -1
smix 1 3 1 50 0 -1
smix 2 4 0 -50 0 -1
smix 3 4 1 50 0 -1

Your proposed 2.2 setting matches the 2.2 wing I fly, so yes.

Hello,
I just tried the current dev version.

The failsafe disable in waypoint mode does not work.
I have provoked a FS in a mission around me in which I have switched off the transmitter.
the FC changed to FS anyway.

Arming over rudder doesn't work either, by the way.

FC F35
Radio Frsky SBUS over R9.

Greetings Sebastian

Hello,
I just tried the current dev version.

Arming over rudder doesn't work either, by the way.

By design, thanks for confirming that.

Did you set:

failsafe_mission =  OFF

to force failsafe to be ignored?

No, I didn't know the parameter.
I'll try it tomorrow.

thanks for the quick feedback.

Greetings Sebastian

Thanks for trying. And confirmation that this change does not break the default case is useful feedback.

As promised. I tried it and it worked. Hooray!
The plane also flies the mission in FS.
Which I haven't tried: FS into a not waypoint mode. if this still works I can't tell now.
it's gotten pretty windy.

A side note that now has nothing to do with INAV:
Is it normal with an R9 system if you don't have a connection (>10 seconds) you had to come to the transmitter very late to get the RC connection back? the telemetry wound was already established.
I had to come back to <600m.

While watching the video recordings of the last mission I noticed something.
I don't know if the "problem" is new or old because I haven't been able to fly big missions yet.

The plane tries to climb as fast as possible to the height of the next waypoint. not linear.

The return flight was even more extreme.
from 600m almost in a dive down to the height of the next point.

here is my update - so far I failed, but will keep on trying in next few days.

before I left for the trip I created WP Mission and saved it to EEPROM, I did this at home when I still had internet connection, using the iNav Configurator 2.1.4
I also saved a text file with all GPS coordinates of my additional missions for different locations that I planned to visit.

when I arrived at my 1st location with mission already saved in EEPROM, I flew the mission with iNav 2.1, all worked as usual. then I updated my FW to 2.2 and wanted to repeat the mission, however after the FW update the mission got erased from EEPROM so I tried to re-create the mission with iNav configurator but being in remote desert area there is no chance of getting internet connection.
I knew my GPS coordinates for the mission (in my text file) and other settings (altitude, speed) but there is actually no way to enter new points in iNav configurator mission planner because without internet the map is blank and the only way to create new way point is to click on the map somewhere. by doing so a random way point is created (somewhere in the world I don't know where) and when I try to edit the waypoint with my actual GPS coordinates, it just disappears from the view and no amount of zooming out will bring the edited waypoint back in view on the blank map.

so next thing I tried, I copied the mission from my text file in this format (I believe this is correct format for iNav) :

wp

#wp 6 valid
wp 0 1 -296112900 1374640500 10000 2250 0
wp 1 1 -295670500 1374743700 10000 2250 0
wp 2 1 -295607000 1374797700 10000 2250 0
wp 3 1 -295465800 1374733900 10000 2250 0
wp 4 1 -295226200 1374621400 10000 2250 0
wp 5 4 0 0 0 0 165

I pasted the the mission in CLI of the configurator and then "save", but as we know when we run "save" command in CLI it reboots FC by default and rebooting FC erases the mission.

so my question is, is there another way to save the mission with CLI command, directly to EEPROM (instead just to FC) ?

if there was an easier way to create missions without internet that would be great, I had to drive 2 days to my current location to get internet connection and create new mission and tomorrow I'll drive back into the desert and hopefully fly the mission with FW 2.2, but after that mission I cannot create any new missions without internet.

I have about 5 different missions saved in my text file but there seems to be no way to save it to EEPROM

cheers

if there was an easier way to create missions without internet that would be great,

There are a number of third party tools you might look at, either cached maps or command line.

• ezgui, mission planner for inav (Android) https://play.google.com/store/apps/details?id=com.ezio.multiwii&hl=en_GB, https://play.google.com/store/apps/details?id=com.eziosoft.ezgui.inav&hl=en]
• MobileFlight (IOS) https://flyinghead.github.io/mobile-flight/
• mwptools (Linux, FreeBSD, Windows [WSL, Cygwin]) https://github.com/stronnag/mwptools
• impload (Linux, Windows, MacOS), command line upload, download, save, restore https://github.com/stronnag/impload

@stronnag
thanks.
I have iPhone (no Android yet) and I'm running Speedybee App with Speedybee BT adapter, all iNav settings work on the App, except mission planning, that one fails, I've reached to Speedybee developers and they replied to say they will work on it.
MobileFlight is no longer supported it seems, there's been no development for over a year, anyway I tried it but MobileFlight refuses to communicate with my Speedybee BT adapter.

I'll have a look at impload for now.

I pasted the the mission in CLI of the configurator and then "save", but as we know when we run "save" command in CLI it reboots FC by default and rebooting FC erases the mission.

so my question is, is there another way to save the mission with CLI command, directly to EEPROM (instead just to FC) ?

there's the mission planner for the smartphone.
you can easily create missions in the field and save them in your mobile phone.
https://play.google.com/store/apps/details?id=com.eziosoft.ezgui.inav&hl=de

otherwise have a look at INAV Configurator 2.2 RC1
now you can also save and load.

just a quick update, some recommendations and a question or two.

been travelling through remote Australian deserts now for 2 weeks and had a fantastic time with the new iNav 2.2 WP Mission with failsafe_mission=off.

btw. to answer my previous question above, there is an easy way to save mission to EEPROM from my pre-created text files - in CLI paste my mission points and then type "wp save", it saves my WP MIssion to EEPROM

• was able to send my AR Wing to remote areas that I cannot access any other way, lost RC link and my model always completed the mission
• sent out my AR Wing and intentionally switched off the radio, it came back every time with mission completed
• sent out my AR Wing on mission and then chased it with my quad (used different radio for my quad)
• sent out AR Wing on mission, switched off radio and drove with my car to another location, had the wing to do few fly overs then wondering somewhere else and eventually had it arrived to my new location for a rendezvous where I took over the control and landed

everything worked as expected, however here are some suggestions :

1. remove restriction "unable to arm" when my first WP is too far

• so I load mission with stick commands, however I don't even know whether I'm going fly the mission or not, yet I'm unable to arm because my 1st WP is say 700m away and my settings for nav_wp_safe_distance = 50000 (500m), ok so I want to change this settings to say 1km, but allowed maximum is only 650m. why ? doesn't make much sense - if we are already allowed to set different WPs several kilometers apart, why can't my 1st waypoint be more than 650m ? I don't know what would settings of "0" do, is that no limit ? either way I would never use no limit but in my opinion something more reasonable than 650m would be appropriate, say something that's within reasonable range of our radios, maybe 2-5km ?
  I understand there needs to be some sanity check feature so that we don't send our model on a mission where the 1st WP is 1000km away because we have entered incorrect GPS data.
• more importantly on this point I don't see any reason why there needs to be any sanity check at all when arming, sanity check should be performed only when I try to activate the WP Mission while already in the air, simply don't execute the mission when my 1st WP is further away than "nav_wp_safe_distance", this would work exactly same as when I forget to load the mission from EEPROM and then try to execute WP Mission - nothing happens
• the way it should work in my opinion is for example my "nav_wp_safe_distance" is set to 500m, but I'm launching 2km away, so fine if I try to execute the WP Mission soon after take-off, then nothing should happen, but as I get closer (1.5km away or closer) then I should be allowed to activate the WP Mission because then I'm already 500m away from my 1st WP

2. Flying out of LOS behind terrain obstacles, ie. mountain range, cliffs, tall rocks,...

• sometimes I plan my WP Mission to fly around these obstacles but then on the way back of RTH was executed I would perhaps hit the obstacle so I also have to plan my return route for the model to come back exactly same way. no big deal but would be much helpful if there was a feature to execute identical return path as my mission out.

3. alternative RTH point.

• first let me ask a question : what happens when my mission has no RTH set (after last WP is reached) and my model already reached my last WP and I have no RC link ? does it loiter around last WP or does it execute my failsafe procedure ? this is important to know, I was worried about it so this is something I did not want to test, I know for sure when I still have radio signal and reach last WP (and have no RTH set up on my mission) then it will definitely loiter around last WP.
  for now I'm assuming if RC link was not recovered by then, the model would execute failsafe procedure, in my case RTH with landing
• would it make sense to request alternative behaviour (for WP Missions only) whereby we could nominate one of our mission WPs to become the new RTH point (only for missions where RTH is not selected after last WP) ? example : say I have 10 WPs and selected no RTH after last WP is reached.
  I send out my model, switch off the radio and drive my car to another location (which happens to be one of my WPs, typically it would be the last one, in this example WP10, but not necessarily, it could be WP8). I suppose for easy implementation if we could do the last WP there would be more than sufficient. this is in case I drove my car to the WP in mind but I arrived late, my model was already there and has left to complete the mission, or actually is already executing failsafe procedure thereby returning home to the launch location, but I'm no longer there because I'm on my way to the rendezvous WP.
• for complete simplicity, I would basically want an option whereby I would select not to execute failsafe procedure upon reaching last WP when the signal was not recovered by then (this could be again some CLI parameter), this option would give me time to arrive with my car at last WP while my model is still loitering around last WP

4. this I think was already suggested, but just to remind, great option to have would be a possibility to set up new mission in flight - as I'm flying (planning my mission) I would want to flick a switch to save the current location as my WP, then next and next and so on, until I save all my WPs, then upon landing I would want to save all created WPs with stick command to EEPROM.
   for next flight I would just load the mission from EEPROM and let the model fly the planned routed on its own

5. violent turns during WP mission - possible smooth arc turns ?

• when letting the model fly WP Mission I can get a nice video footage on a calm day, except for any change of direction, it basically ruins the footage because all turns are extremely violent, as if full elevon deflection is used instantly, I also noticed the immediate increase of throttle.
  I understand that for some sharp turns (more than 90deg) it may be sharp, but this is happening even when I plan my mission with easy 10deg turns at a time. I noticed when the model is supposed to make say 10deg turn to the right (based on my WPs setup), when it reaches given WP it would actually turn left and then sharply right and the turn is really violent.
  not sure what the reason is behind this but would prefer alternative behaviour with more like "human" flying where we actually make preplanned wide smooth arc turns. the given WP should actually be centre point of a radius around which I would want my model to around smoothly

6. this I think was also already mentioned by somebody else - same problem as 5) above but in regards to altitude change, this should be more linear instead of full power/maximum angle climb (potentially killing a battery) or maximum velocity dive

7. OSD system messages during WP Mission are somewhat insufficient, I never know where exactly my model is, it should really tell us WP number and also when RTH is selected at the end of the mission it should then read "RTH" instead of "enroute to waypoint"

8. this is potentially a bug - after WP Mission is complete and RTH was selected after last WP then upon returning home the model does not descent to the "nav_rth_home_altitude"

anyway, all in all this feature implementation has been fantastic, let me know if it would be more appropriate to submit these as feature requests ?

from my perspective the points 1), 3) and 7) should be relatively "easy" to implement if they make sense and probably most beneficial. points 5) & 6) also very beneficial if our goal is smooth footage but understand those last 2 points are somewhat complicated to implement perhaps.

cheers
Pete

@peteoz thanks for the feedback. Please consider opening new issues (if there are none yet) instead on commenting on a merged PR.